Ongoing developments in the semiconductor industry have led to more and more circuitry being placed on a single integrated circuit. Therefore, a large number of functions, which formerly would have been distributed across multiple integrated circuits mounted on a printed circuit board, may now be aggregated on the single integrated circuit, generally known as a microchip. This aggregation, sometimes referred to as a system-on-a-chip (SOC), has the advantage of reducing the number of components in a system, as well as reducing cost, overall power consumption, manufacturing complexity, and so forth.
SOCs typically use embedded processors, i.e., programmable microcontroller and digital signal processor cores, coupled to embedded memories and a myriad of peripheral modules on a single integrated circuit. Examples of devices having embedded processors are cellular telephones, computer printers, high performance disk drives for computer data, automobile control systems, and the like. As a result of the rapid development and commercialization of SOCs, product developers are faced with the overwhelming task of realizing these complex devices with increasingly reduced visibility of subsystem interaction. One problem associated with the development of an SOC is the design validation and debugging of programs which are to run on the SOC.
A variety of approaches have evolved to develop and debug programs on embedded processors. One such approach is to integrate or embed emulation circuits in the processor, sometimes referred to as “on-chip emulation.” This approach is becoming increasingly common as embedded processors have achieved progressively higher processing speeds and register widths, thus increasing the needed output bandwidth. This type of emulation, referred to herein as on-chip debug capability, typically includes circuits to monitor the state of an embedded processor, to configure the state of an embedded processor, and to communicate with an external debug tool. The external debug tool is commonly connected to a host computer running debugging software, and acts as a translator between the on-chip debug capability and the host computer.
Unfortunately, this on-chip debug capability can also be used by hackers and other unauthorized persons to perform reverse engineering on a product to determine how a product operates. This on-chip debug capability can also be exploited to create malicious code and viruses to make a product perform functions that were not intended by the product developer. In order to prevent this, it is desirable to provide means by which the original product developer is permitted to use the on-chip debug capability during product development and field debug, but to disable the on-chip debug capability in operational field usage to prevent others from misusing this capability.
Traditionally, this has been accomplished by producing two different products, one with on-chip debug capabilities for product development and one with on-chip debug capabilities removed for operational fielded products. This is an expensive solution that prevents use of on-chip debug capabilities for legitimate field debug needs. In addition, this “solution” creates a situation in which differences exist between the development and operational environments. Other techniques include methods to cut traces, or otherwise disconnect the debug capability connections in a fielded product. These techniques offer little real protection and adversaries can readily learn how to re-connect the on-chip debug capabilities.
Thus what is needed is a technique for selectively enabling an on-chip debug capability for those who are authorized to utilize the capability.